The 3rd Generation Partnership Project (3GPP) unites a number of telecommunications standard development organizations and provides their members with an environment in which to develop specifications for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities. 3GPP specifications also provide hooks for non-radio access to the core network, and for interworking with other networks.
The latest evolution of the 3GPP core network architecture for wireless communications is referred to as the Evolved Packet Core (EPC). EPC was first introduced by 3GPP in Release 8 of the standard. It was designed to have a “flat architecture” in order to handle data traffic efficiently from a performance and cost perspective, and few network nodes are involved in the handling of traffic. Protocol conversion is also generally avoided. It was also decided to separate the user data (also known as the “user plane”) from the signaling (also known as the “control plane”), which enables network operators to dimension and adapt their networks easily.
FIG. 1 is a basic architecture diagram illustrating a User Equipment (UE) 104 (e.g., a mobile phone or other wireless device) connected to the EPC 102 over E-UTRAN (LTE access network). The Evolved NodeB (eNodeB) 106 is the base station for LTE radio. In this figure, the EPC is composed of four network elements: the Serving Gateway (Serving GW) 110, the Packet Data Network Gateway (PDN GW) 112, the MME 114 and the HSS 116. The EPC may be connected to external networks 108.
The HSS (for Home Subscriber Server) 116 is a database that contains user-related and subscriber-related information. It also provides support functions in mobility management, call and session setup, user authentication and access authorization.
The gateways (Serving GW 110 and PDN GW 112) deal with the user plane. They transport IP data traffic between the User Equipment (UE) and the external networks. The Serving GW 110 is the point of interconnect between the radio-side and the EPC. As its name indicates, this gateway serves the UE by routing incoming and outgoing IP packets. It is the anchor point for intra-LTE mobility (i.e. in case of handover between eNodeBs) and between LTE and other 3GPP accesses. It is logically connected to the other gateway, the PDN GW.
The PDN GW 112 is the point of interconnect between the EPC and external IP networks, such as the Internet. These networks are called PDN (Packet Data Network), hence the name. The PDN GW routes packets to and from the PDNs. The PDN GW also performs various functions such as IP address/IP prefix allocation or policy control and charging. 3GPP specifies these gateways independently but in practice they may be combined in a single “box” by network vendors.
The MME (for Mobility Management Entity) 114 deals with the control plane. It handles the signaling related to mobility and security for E-UTRAN access. The MME is responsible for the tracking and the paging of UEs in idle-mode. It is also the termination point of the Non-Access Stratum (NAS).
As show in FIG. 1, a UE 104 can reach the EPC 102 using E-UTRAN, however this is not the only access technology supported. 3GPP specifies support of multiple access technologies and also the handover between these accesses. The idea is to bring convergence using a unique core network providing various IP-based services over multiple access technologies. Existing 3GPP radio access networks are supported. 3GPP specifications define how interworking is achieved between an E-UTRAN (LTE and LTE-Advanced), GERAN (radio access network of GSM/GPRS) and UTRAN (radio access network of UMTS-based technologies WCDMA and HSPA).
The architecture also allows non-3GPP technologies to interconnect the UE and the EPC. Non-3GPP means that these accesses were not specified in 3GPP. These technologies include, for example, WiMAX, Cdma2000®, WLAN or fixed networks. Non-3GPP accesses can be split into two categories: the “trusted” ones and the “untrusted”. Trusted non-3GPP accesses can interact directly with the EPC. Untrusted non-3GPP accesses interwork with the EPC via a network entity called the ePDG (for Evolved Packet Data Gateway) (not shown). The main role of the ePDG is to provide security mechanisms such as IPsec tunneling of connections with the UE over an untrusted non-3GPP access. 3GPP does not specify which non-3GPP technologies should be considered trusted or untrusted. This decision is made by the operator.
The 3GPP network architecture illustrated in FIG. 1 was originally designed to enable communication between devices that are traditionally operated by humans. For example, the 3GPP network is well suited for providing a smart phone with access to a packet switched network such as the internet and a circuit switched network such as a Global System for Mobile Communications (GSM) network. The 3GPP network was not originally designed in a way that is optimized for handling so called machine-to-machine (M2M) communications, also referred to as machine type communications (MTC), in which machines, or devices, communicate with each other over the network, such as communications involving smart metering, home automation, eHealth, consumer products, fleet management, etc.
In Release 11 (R11) of the 3GPP specifications, 3GPP enhanced the interworking capabilities of the UMTS core network for machine type communications/machine-to-machine communications. Interworking refers to a server, or application, interfacing to the core network for the purposes of exchanging information, controlling devices, or monitoring devices, or communicating with devices. FIG. 2 shows the MTC architecture that is presented by 3GPP in TS 23.682 V11.5.0.
As illustrated in FIG. 2, a service capability server (SCS) 212 may provide services to the core network, devices, and applications. The SCS may also be called an M2M Server, MTC Server, a Service Capability Layer, or a Common Services Entity (CSE). An SCS 212 may be controlled by the operator of the home public land mobile network (HPLMN) or by an MTC service provider. An SCS may be deployed inside or outside the operator domain. If an SCS is deployed inside the operator domain, the SCS may be an internal network function and may be controlled by the operator. If an SCS is deployed outside the operator domain, the SCS may be controlled by a MTC service provider.
An SCS may communicate with a machine type communication (MTC) interworking function (MTC-IWF) 210 via a Tsp reference point (i.e., interface). The Tsp reference point is an example of an interface that is used for interworking with the core network.
As further illustrated in FIG. 2, the reference point (i.e. interface) Tsms 202 may connect a short message service (SMS) service center (SMS-SC) 204 to a short message entity (SME) 206. The Tsms reference point is another example of an interface that is used for interworking with the core network. The SMS-SC 204 communicates with the MTC-IWF over a T4 reference point.
As also illustrated in FIG. 2, the SCS 212 may be an entity that may connect to a 3GPP network to communicate with user equipment MTC (UE MTC) application 216, the MTC-IWF 210 in the HPLMN (e.g., as defined by the boundary 218) or a SMS-SC 204 for device triggering. The SCS 212 may offer capabilities for use by one or more application server MTC (AS MTC) applications.
A UE may communicate through the public land mobile network (PLMN), which includes radio access network (RAN) 219, with SCS(s) and/or other MTC UE(s). An MTC UE 214 may host one or more MTC applications 216. The MTC applications may also be hosted on one or more ASs 220/222. The MTC application 216 may be a MTC communication endpoint that may interact with SCSs 212, AS MTC applications, or other UE MTC applications.
An application server (AS) 220/222 may also host one or more MTC applications. An AS may interface with SCS(s) 212 or a GGSN/P-GW 224. The MTC applications on an AS may interact with SCSs, UE MTC applications, or other MTC applications.
The MTC inter working function (MTC-IWF) 210 may hide the internal PLMN topology from the SCS 212. The MTC-IWF may relay and/or translate signaling protocols used between itself and the SCS (e.g., over the Tsp reference point 208) to support MTC functionality (e.g., MTC UE triggering) in the PLMN. For example, the SCS may request that the MTC-IWF send a trigger to a MTC device. The MTC-IWF may deliver the MTC trigger to the MTC device 214 via SMS. The MTC device 216, based on the trigger, may respond to the SCS 212. The MTC device 216 may, for example, respond with a sensor reading. When the MTC device 216 responds to the SCS 212, the MTC device may use a packet data network (PDN)/packet data protocol (PDP) connection to communicate with the SCS 212. The MTC device may connect with the SCS using an IP connection.
The MTC-IWF 210 may authorize an SCS 212, before the SCS may establish communication with a 3GPP network. For example, when the SCS 212 makes a trigger request on the Tsp reference point, the MTC-IWF 210 may check whether the SCS is authorized to send the trigger request and that the SCS has not exceeded its quota or rate of trigger submissions.
As further shown in FIG. 2, a mobile switching center (MSC) 238 is the primary service delivery node for GSM/CDMA, responsible for routing voice calls and SMS as well as other services (such as conference calls, FAX and circuit switched data). The MSC sets up and releases the end-to-end connection, handles mobility and hand-over requirements during the call and takes care of charging and real time pre-paid account monitoring.
A serving general packet radio service (GPRS) support node (SGSN) 234 is responsible for the delivery of data packets from and to mobile devices within its geographical service area. Its tasks include packet routing and transfer, mobility management (attach/detach and location management), logical link management, and authentication and charging functions. The location register of the SGSN stores location information (e.g., current cell, current VLR) and user profiles (e.g., IMSI, address(es) used in the packet data network) of all GPRS users registered with it.
M2M/MTC communications differ from traditional data communications that involve human interaction. For example, M2M/MTC applications that require data communication do not all have the same characteristics. Each type of M2M/MTC application may require different types of communication services. 3GPP TS 22.368 identifies these different service requirements and lists different MTC features to provide these services. For example, the MTC Feature ‘Low Mobility’ is intended for use with MTC Devices that do not move, move infrequently, or move only within a certain region. The MTC Feature ‘Time Controlled’ is intended for use with MTC Applications that can tolerate to send or receive data only during defined time intervals and avoid unnecessary signaling outside these defined time intervals. The MTC Feature ‘Small Data Transmissions’ is intended for use with MTC Devices that send or receive small amounts of data. The MTC Feature ‘Infrequent Mobile Terminated’ is intended for use with MTC Devices that mainly utilize mobile originated communications. The MTC Feature ‘MTC Monitoring’ is intended for monitoring MTC Device-related events. The MTC Feature ‘Secure Connection’ is intended for use with MTC Devices that require a secure connection between the MTC Device and MTC Server/MTC Application Server. Lastly, the MTC Feature ‘Group Based’ applies to a group of MTC devices, and includes group based policy, group based addressing, etc.
In existing 3GPP networks, application layer data communication is mainly supported through the packet domain and through SMS. Several different transport mechanisms are available, including (i) packet domain (via the SGi and Gi reference points, (ii) short message service (SMS), (iii) multimedia messaging service (MMS), and (iv) the Non-Access Stratum (NAS).
With respect to packet domain messaging, the PGW and GGSN act as the anchor point for data communication and they route user plane data through the GTP-U tunnels (PMIP may also be used in S5/S8 interfaces) within the core network. 3GPP TS 23.401 defines this EPC architecture. A GTP-U tunnel provides common QoS treatment to the IP flows transported through them. Packet filters decide the flows that are to be transported through a specified GTP-U tunnel.
The purpose of SMS is to provide the means to transfer short text messages between a MS/UE and a SME (Short Message Entity) via a SC (Service Centre), as described in 3GPP TS 23.040. SMS is mainly used to exchange short text messages between users. However SMS can also be used by some higher layer applications for short data communication. SMS can also provide a store and forward mechanism. SMS is routed differently than regular user plane data as and does not generally use the SGi/Gi interface path.
MMS is a service that is used to provide a rich set of content to subscribers in a multimedia messaging context. It provides a store-and-forward usage paradigm similar to SMS. However, MMS uses the packet domain user plane (SGi/Gi) to transport the multimedia messages. MMS can be considered an application level service running over the user plane. 3GPP TS 23.140 describes the MMS architecture. MMS supports the use of email addresses (RFC 2822) or MSISDN (E.164) or both to address the recipient of a multimedia message. MMS may also support the use of service provider specific addresses to address the recipient of an multimedia message.
As for NAS, there has been discussion within 3GPP SA2 about allowing the MTC-IWF to use the T5 interface to send small data messages to the SGSN/MME and then using a NAS or RRC message to send the data to the UE. This feature is not yet supported by 3GPP, but it is anticipated that in the future some such service may be supported.
Another existing mechanism for data transport in a 3GPP network is called device triggering. Device Triggering is the means by which a SCS sends information to a UE via the 3GPP network to trigger the UE to perform application specific actions that include initiating communication with the SCS. 3GPP TS 23.682 defines the device triggering mechanism supported by 3GPP networks. Device Triggering is required when an IP address for the UE is not available or reachable by the SCS/AS.
In order to determine if device triggering is necessary, the SCS/AS will have to track the validity of the device's IP address. It is possible that the network/PDN may re-allocate the IP address assigned to a M2M device to another UE if the device has been idle for too long. In some cases, the SCS/AS may try initial communication using the device's IP address known at the SCS/AS and may detect that the IP address is invalid after the communication fails (probably based on ICMP messages). This could be time-consuming for establishing a communication with a M2M device. Also, the existing device triggering approach requires the SCS/AS to determine if device triggering is needed before exchanging application data, and the SCS/AS will have to build a device triggering message and initiate the device triggering procedure.